AWS WAFのAnonymous IP Listルールグループ導入下の環境に対しMackerelのURL外形監視を行うための設定
はじめに
清水です。AWS WAFの匿名IPリスト（Anonymous IP List）マネージドルールグループを導入した環境下に対して、監視サービスMackerelのURL外形監視を行おうとするとAnonymous IP Listマネージドルールグループ内のHostingProviderIPListルールでブロックされてしまいます。本エントリではこの事象の確認と、AWS WAFのScope-down statementを使用してAnonymous IP Listマネージドルールグループを適用しながら同時にURL外形監視を行う方法をまとめます。
AWS WAF導入済みの環境にMackerelのURL外形監視を設定
まずは、AWS WAFのAnonymous IP Listマネージドルールグループを導入してある環境に、MackerelのURL外形監視を適用するとどのような状況になるのか確認しておきましょう。
AWS WAFを導入した環境の準備
ALB配下にEC2を稼働させて、アクセスすると「200 OK」の文字列とステータスを返す環境を作成しました。
ここにAWS WAFのAnonymous IP Listマネージドルールグループを設定したWeb ACLを関連付けます。
MackerelのURL外形監視を設定
この環境（URL）に対して、監視サービスMackerelでURL外形監視を設定します。
監視対象のURL部分に対象となるドメインを指定、監視ルール名を設定し、その他アラート発生までの最大試行回数や証明書の有効期限の監視なども設定しておきました。
設定が完了しました。
URL外形監視がWAFでブロックされてしまうことの確認
設定完了後、しばらくするとアラートが上がってしまいます。403エラーとなっている状況ですね。
自分の環境からブラウザで該当URLを参照すると「200 OK」が返ってる状態です。ということは、AWS WAFによってブロックされている可能性が考えられます。WAFのマネジメントコンソールから状況を確認してみましょう。
該当時間帯に「AWS#AWSManagedRulesAnonymousIpList#HostingProviderIPList」でBLOCKされているリクエストがありました。詳細を確認してみるとUser-AgentヘッダからMackerelの外形監視のリクエストであることがわかります。
Mackerelの外形監視についてはリクエスト元IPアドレスが以下で公表されています。こちらの一つとも合致しますね。
ということで、MackerelのURL外形監視のためのリクエストが、AWS WAFのAnonymous IP Listマネージドルールグループ内、HostingProviderIPListルールでブロックされてしまうことが確認できました。
AWS WAFのブロックを回避してURL外形監視ができるようにする
それではMackerelのURL外形監視のリクエストについて、AWS WAFのHostingProviderIPListルールでのブロックを回避する方法を検討します。
Count modeへの切り替えはどうか
ブロック回避の方法の一つとして、ブロックしているルール「HostingProviderIPList」をCountモードにしてしまうことも検討できるかと思います。しかしこの場合、Mackerelの外形監視のためのリクエスト以外のホスティングプロバイダ経由のリクエストもブロック対象外となってしまいます。AnonymousIPListルールの使用のみが主目的であり、HostingProviderIPListルールによる防御はしなくてもよい、という状況であればこちらでもかまいませんが、HostingProviderIPListルールによる防御を行いたい場合、Countモードにしてしまうのは適切ではありません。
Scope-down statementの使用
AWS WAFにはScope-down statementという、ルールによって評価されるリクエストの範囲を絞り込む機能があります。
マネージドルールに対しては、このScope-down statementに該当したリクエストのみをルールグループで評価する、といった使い方が可能です。今回のケースでは「MackerelのURL外形監視に使われるIPアドレス」以外のリクエストに対してルールグループで評価を行いたい（「MackerelのURL外形監視に使われるIPアドレス」からのリクエストであればルールグループでの評価は行わないようにしたい）わけですが、Scope-down statementでは「リクエストがsatementに合致しなかった場合に」という条件が利用できるので、これが実現できます。
実際に設定をしながら確認してみましょう。まずstatementの条件となるIPアドレスの指定はIP setを使用しますので、これを作成します。
AWS WAFのマネジメントコンソール、IP setsのページから、適用するWeb ACLと同じリージョンを選択して[Create IP set]ボタンから進みます。IP set nameやDescriptionを適切に入力、RegionがWeb ACLと同じことを確認します。IP versionではIPv4を選択して、IP addressesにMackerelからの外形監視リクエストのリクエスト元IPアドレスレンジを入力します。
IP setが作成できたら、続いてScope-down statementを設定します。WebACLのRulesから対象となるAWS-AWSManagedRulesAnonymousIpListルールグループを選択してEditで進みます。
Scope-down statementの項目で、Enable scope-down statementのチェックをonにします。設定項目が現れるので以下のように設定して[Save rule]で保存します。
- If a request
doesn't match the statement (NOT)
- Statement
- Inspect
Originates from an IP address in
- IP set
- ipset-exclude-anonymousiplist （先ほど作成したIP set）
- Inspect
- IP address to use as the originating address
- Source IP address
設定が保存され、Set rule priorityのページに遷移します。ここでは特に設定する必要がないので、CancelボタンでWeb ACLのページに戻ります。なおこちらの画面でも確認できますが、Scope-down statementを設定することでCapacity、つまりWCU（Web ACL Capacity Unit）を1つ消費している点に注意しましょう。（Scope-down satementによるWCUの消費について詳細はドキュメントをご確認ください。ここでは1ですが条件により変わることもあるようです。IP セット一致ルールステートメント - AWS WAF、AWS Firewall Manager、および AWS Shield Advanced）
Scope-down statementの設定後、しばらくするとMackerelの外形監視の障害がクローズされていることが確認できました。
AWS WAFのマネジメントコンソール、Sampled requestsからも、MackerelのURL外形監視のリクエストがALLOWで許可されていることが確認できます。
なお、Scope-down statementではHeaderの内容でもルールグループ評価対象となるstatementを設定できます。MackerelのURL外形監視のHTTPリクエストヘッダの内容でルールグループ評価対象外とする、といったこともできそうですね。
Mackerelの外形監視リクエスト元IPアドレスとHostingProviderIPListルールでのブロックについて
MackerelのURL外形監視のリクエストがAWS WAFのHostingProviderIPListルールでブロックされてしまうことの確認と、回避する方法についてまとめました。ここでは、なぜMackerelのURL外形監視のリクエスト元IPアドレスがブロックされてしまうのかを確認しておきましょう。
ブロックしたHostingProviderIPListルールについて、AWSドキュメントで以下のように記載があります。
エンドユーザートラフィックのソースになる可能性が低いホスティングプロバイダーとクラウドプロバイダーの IP アドレスのリストを検査します。例には、AWS などのクラウドプロバイダーがあります。
AWS管理ルールルールグループリスト - AWS WAF、AWS Firewall Manager、および AWS Shield Advanced
Mackerelからの外形監視リクエストのリクエスト元IPアドレスレンジについて確認してみると、AWSのIPアドレスレンジを使用しているものがあることが伺えます。（すべてを確認したわけではないのですが、いくつかはip-ranges.jsonで確認できるIPアドレスレンジに含まれることを確認しました。（AWS IP アドレスの範囲 - AWS 全般のリファレンス））
以下の資料のように、Mackerel自体のインフラ基盤もAWSを利用しているようなので、URL外形監視のリクエスト元IPアドレスがAWSである、ということも納得できますね。
そしてHostingProviderIPListルールの説明の通り、AWSのIPアドレスについてはHostingProviderIPListルールのブロック対象となってしまうため、ブロック回避が必要になる、ということです。
HostingProviderIPListルールでAWSのIPがブロックされてしまうことと回避方法については、以下エントリでも扱っていますので合わせてご確認ください。
まとめ
AWS WAFのマネージドルールグループAnonymous IP Listを導入した環境にMackerelのURL外形監視を設定するとHostingProviderIPListルールでブロックされてしまうこと、そしてScope-down statementをAnonymous IP Listルールグループに適用してこのブロックを回避する方法についてまとめてみました。WAFを導入してる環境に外形監視を行う場合には、リクエスト元IPアドレスやその他ヘッダ情報なども確認し、WAFのルールと照らし合わせブロックされないか確認することが重要かと思います。
![[アップデート] AWS Amplify のファイアウォール（WAF）機能がついにプレビューで登場しました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-875a3d2bbdba43ad15684c9ee2e357b1/c77a61f7c646b6997c54cc55538ec251/aws-amplify)
